STREAMS is a software environment developed by American Telephone and Telegraph Company for use with the "UNIX" operating system ("UNIX" is a registered trademark of UNIX System Laboratories, Inc.). STREAMS has been incorporated into recent versions of "UNIX" and is a standardized part of "UNIX" System V, Release 4. STREAMS provides developers with functions, utility routines and facilities that assist in software design and development. The STREAMS mechanism provides a standardized means for gaining access to "UNIX" system communication services.
Central to understanding STREAMS is the notion of a "stream". A "stream" is a full duplex data transfer path between a user process and a driver in the kernel space of the "UNIX" operating system. The kernel space of "UNIX" is the portion of the operating system that interacts with hardware to provide a set of services that can be utilized by user programs. The "UNIX" operating system also includes a shell, for reading and interpreting commands.
FIG. 1 provides an illustration of the data flow in an example stream 21. The stream 21 provides a full duplex data transfer path between a user process 24 residing within a user space 20 and a driver 30 residing within a kernel space 22. The kernel space 22 is a privileged area that user programs may not access except through system calls. The driver 30 is connected to at least one peripheral device through an external interface 32. The stream 21, thus, facilitates a data path between the user process 24 and at least one peripheral device.
Each stream 21 includes a stream head 26 situated at the end of the stream that is nearest to the user process 24. The stream head 26 processes system calls made by the user process 24 to convert the system calls into appropriately formatted messages that are sent down the stream 21. In general, a user may gain access to facilities provided by the software environment through STREAMS-specific system calls. These system call include the open(2) system call that recognizes a STREAMS file and creates a stream to a specific driver. Other system call include the read(2) and write(2) system calls which receive and send data on a stream. The close(2) system call dismantles a stream, and the ioct1(2) system call enables a user to perform functions specific to a particular device. Lastly, the putmsg(2) and getmsg(2) system calls enable a user to send and receive STREAMS messages, respectively.
As mentioned above, the stream 21 also includes driver 30. Driver 30 may be either a device driver for driving at least one peripheral input/output (I/O) device or a software driver (known as a pseudo-device driver) that does not drive a hardware device but, instead, interprets messages. The driver 30 typically handles data transfer between the kernel and the peripheral devices that are coupled to it through the external interface 32, but performs little processing of data other than conversion between data structures used by the STREAMS mechanism and data structures used by the coupled devices.
A stream may also include one or more modules, such as module 28 in stream 21. Modules are added and removed from a stream by system calls. In particular, the ioct1 I.sub.-- PUSH system call adds a module to a stream beneath the stream head 26, and the ioct1 I.sub.-- POP system call removes the module closest to the stream head from the stream. The pop of the module calls the "close" procedure of the module.
Module 28 processes data flowing on the stream 21 by performing intermediate transformations on messages that pass between the stream head 26 and the driver 30. The module 28 is a defined set of kernel-level routines and data structures used to process data, status information, and control information. Each module in a stream is self-contained and functionally isolated.
Data is passed between the driver 30 and stream head 26 in the form of messages. These messages are passed by making calls to the putmsg or getmsg system call. Messages that are passed from the stream head 26 to the driver 30 are referred to as "downstream" messages. On the other hand, messages that are passed from the driver 30 to the stream head 26 are referred to as "upstream" messages. In STREAMS, a message is a set of data structures used to pass data, status information and control information. Each STREAMS message includes at least one message block. A message block is a 3-tuple comprising a header, a data block and a data buffer.
Messages are held at different stages of the stream 21 by queues. The queues serve as interfaces, between drivers or modules and the rest of the stream 21. Queues are allocated in pairs: an upstream queue that receives messages being sent upstream and a downstream queue that receives messages being sent downstream. For instance as shown in FIG. 2, module 36 includes upstream queue 42u and downstream queue 42d, and module 38 includes upstream queue 44u and downstream queue 44d. Driver 40 also includes an upstream queue 47u and a downstream queue 47d.
The queues 42u, 42d, 44u, 44d, 47u and 47d temporarily hold messages as the messages are passed up and down the stream 21. Often times, a queue may hold more than one message at a time. In such instances, as shown in FIG. 3, the first message in the queue (denoted as "message 1") includes a pointer 51 to the next message in the queue (i.e., message "2") and a pointer 53 to the queue header 49. The queue header 49 is a header positioned at the beginning of the linked list of the queue. The message blocks 46 that form "message 1" are linter-connected to form a linked list. Similarly, the message blocks 48 that form "message 2" are connected in a linked list.
A stream is constructed as a linked list of kernel resident data structures. Specifically, the linked list is created as a set of linked queue pairs. Kernel routines interface with the stream head to perform operations on the stream. Each queue includes an "entry point" which points to a procedure that processes messages received by the respective queue.
In the illustrated stream 21 of FIG. 1, the stream is a linear connection to modules, wherein each instance of a module is connected to at most one upstream module and at most one downstream module. While this configuration is suitable in many instances, certain applications require the ability to multiplex multiple streams in a variety of configurations. Therefore, the STREAMS software environment provides a multiplexer structure that multiplexes upper streams (streams that are upstream from the multiplexer) with lower streams (streams that are downstream from the multiplexer).
More information regarding the STREAMS environment is provided in the "UNIX System V, Release 4.0 STREAMS Guide", 1990, American Telephone and Telegraph Company.
One problem with the STREAMS environment is that it cannot be used in a distributed fashion. In other words, a system may not access drivers resident on another system.
It is, therefore, an object of the present invention to provide a distributed software environment for development of system communication services.